home *** CD-ROM | disk | FTP | other *** search
/ Hottest 6 / Hottest 6 (1996)(PDSoft)[!].iso / software / fredfish / 1007.lha / Programs / AIBB / Version_Changes < prev    next >
Text File  |  1994-01-19  |  39KB  |  704 lines

  1.  
  2.                                 A.I.B.B.
  3.                     Amiga Intuition Based Benchmarks
  4.                        Program Release Version 6.5
  5.                     Copyright 1991-1993 LaMonte Koop
  6.                           All Rights Reserved
  7.  
  8.                        Version Change Information
  9.  
  10.  
  11.     Version series' 4.x-6.x of AIBB is a complete re-write from the original
  12. code used for the previous versions 1-3.  Being that this is the case, it
  13. is quite important that the documentation be read thoroughly in order
  14. to completely understand all aspects of the program performance.  The
  15. changes to this version series are detailed below.
  16.  
  17. Changes to version 6.5:
  18.  
  19.     --     AIBB now uses only one window instead of two for the Main and
  20.         System Information displays.  This has two advantages: One,
  21.         when AIBB used the two window system, BACKDROP windows were not
  22.         possible.  Because of this, certain requesters with depth-arranging
  23.         gadgets could end up being lost behind the currently displayed
  24.         window and thus lock the user out.  This is no longer a problem
  25.         now as the single window in use is of type BACKDROP.  Secondly,
  26.         less CHIP RAM is used in this configuration.  The downside to all
  27.         this is somewhat more time is taken when switching between the
  28.         two displays.  This is most noticable on slower systems, although
  29.         every effort has been made to minimize this delay.
  30.  
  31.     --     A race condition in the internal function UpdateSys() has been
  32.         fixed.  Previously it was possible for this function to break its
  33.         own Forbid() state under certain race situations while accessing
  34.         one of the system shared resource lists.  This could possibly
  35.         result in a list entry being pulled out from under the function if
  36.         a context switch to another task took place when the Forbid() was
  37.         broken.  The situation would be rare, but for safety reasons it has
  38.         been corrected as of this release.
  39.  
  40.     --     A bug was fixed in that AIBB would erroneously report memory
  41.         on an A1200 located at $00c00000 as being of the "SLOW-FAST"
  42.         variety.  AIBB now does consistancy checks to ensure that what it
  43.         is reporting is indeed "SLOW-FAST" or "Ranger" memory.
  44.  
  45.     --     Various internal cleanups were done including dead code/data
  46.         elimination and optimizations of existing code.
  47.  
  48. Changes to versions 6.2 - 6.4:
  49.  
  50.         *** Versions 6.2 - 6.4 were internal test releases only.
  51.  
  52. Changes to version 6.1:
  53.  
  54.     --     Some modifications were made to the way AIBB does MMU table
  55.         translations (such as looking up the ROM image location) on 68040
  56.         machines to correct a few problems and wrong results which occured
  57.         with the original setup.  Specifically, AIBB was incorrectly using
  58.         the SFC register to indicate the address space to look at with the
  59.         PTEST instruction rather than the DFC register which is correct.
  60.         This usually worked in the past as the DFC register generally
  61.         already reflected the proper address space, but in a few
  62.         circumstances erroneous results could occur.  Fixed.
  63.  
  64.     --     General code clean up and reduction has resulted in an
  65.         approximate 10K of size reduction in AIBB's executable.
  66.  
  67.     --     A few more boards were added to AIBB's internal expansion board
  68.         database.
  69.  
  70. Changes to version 6.0:
  71.  
  72.      --    AIBB has had its graphics-based tests completely re-written.
  73.         The user is now allowed to select the screen mode to be used by
  74.         AIBB when performing such tests via the "Set Gfx Test Mode" option
  75.         under the "Test Options" menu.  This is done via the ASL.LIBRARY
  76.         screenmode requester, and thus this option is not available unless
  77.         the host system is using V38 of ASL or greater (V38 is found with
  78.         the AmigaOS 2.1 enhancement).
  79.            The default screen mode AIBB uses for its graphics tests is
  80.         a high-resolution ( 640x200 ) 3 bitplane ( 8 color ) setup.  When
  81.         a new screen mode is selected for the tests, AIBB will check this
  82.         against the modes used in the comparison systems and will warn the
  83.         user if the new mode differs in equivalence, as it is necessary to
  84.         be aware of this so that the comparisons can then be weighted
  85.         accordingly. ( eg, if you run a test in a low-res 1 bitplane mode,
  86.         it will almost assuredly perform faster than in a high-res 4
  87.         bitplane mode, so this has to be taken into account when looking at
  88.         the results ).
  89.            This new option was provided for allowing the comparison of
  90.         different graphics modes on the systems used.  It can also be used
  91.         to examine the performance of some of the new graphics boards being
  92.         introduced for the Amiga. ( for example, one can see at which mode
  93.         the board ends up being slower for a given test than the default
  94.         mode used for the comparison systems ).
  95.            AIBB does save the screen mode data within its load module, so
  96.         that this information is available when a new module is loaded.
  97.         Again, when a module is loaded, checks are made against the screen
  98.         modes in use by the other loaded systems, and the host system, to
  99.         warn the user if differing graphics modes were used.
  100.            In addition to these changes, another item under the "Test
  101.         Options" menu allows the user to browse through the graphics modes
  102.         used by the comparison systems, as well as that in use by the host
  103.         system.
  104.            Please note: All of these changes have meant that AIBB's load
  105.         module and preferences file format have changed.
  106.  
  107.      --    The ability to change AIBB's primary screen colors has been
  108.         added via the use of a color requester.  Color selections are
  109.         saved to AIBB's preferences file when the "Save Configuration"
  110.         menu item is selected in AIBB's "General" menu area.  This was
  111.         added upon complaints from monochrome monitor users who were
  112.         having trouble seeing parts of AIBB's display because two or
  113.         more colors would map to the same grey shades.
  114.  
  115.      --    AIBB's help mode requesters have been removed to make room for
  116.         the changes to its graphics tests.  They were giving problems due
  117.         to a compiler bug (bad code generation) in any case, and the entire
  118.         system needs to be re-worked before being implemented again
  119.         (space allowing).  This also freed up a good deal of space for
  120.         other functions within AIBB, and unless it becomes a real problem
  121.         this may not be re-implemented...at least not in the form it has
  122.         taken thus far.
  123.  
  124.      --    AIBB will no longer show 2 gadgets on a requester when only one
  125.         option is available.  This has been changed as it was reported to
  126.         be confusing to some users when two gadgets would appear, though
  127.         they had the same text/action associated with them.
  128.  
  129.      --    Under 1.3 or earlier of AmigaOS, AIBB would sometimes call up
  130.         an Alert indicating a lack of CHIP memory for a particular
  131.         operation when in fact there was no problem.  This was due to a bug
  132.         in the AmigaOS Request() function under 1.3 and below.  This
  133.         function would not always give the proper return value, and would
  134.         make AIBB believe an error occured when it in fact hadn't.  A
  135.         workaround is in effect now for 1.3 and below within AIBB, by
  136.         looking at window->FirstRequest instead of relying on the return
  137.         value from Request() to indicate success.
  138.  
  139.      --    AIBB's TGTest has been changed again to one which carries its
  140.         measure in terms of characters/second output to the screen.  The
  141.         previous use of variously sized windows to hold the output has been
  142.         removed due to various testing which showed it to have a minimal
  143.         value in the test itself.
  144.  
  145.      --    A new entry in AIBB's memory node information reporting has
  146.         been added.  AIBB will now report the a relative "Bus latency
  147.         factor" for all FAST RAM nodes.  This figure represents the latency
  148.         between a memory cycle, and when another cycle can be performed.
  149.         Lower ratings indicate better response times for a particular
  150.         memory node, with the unattainable goal of 0.0 indicating that no
  151.         latency occured at all.  Basically, this gives information as to
  152.         the relative efficiency of various memory nodes.  (eg, one with a
  153.         rating of 5.0 would be more efficient, and hence faster than one
  154.         with a rating of 7.0.).  Note that this can only be used as a
  155.         valid comparison across systems if other factors such as processor
  156.         type, clockspeed, and bus width are also taken into account.  This
  157.         figure is most useful in comparing two different memory regions on
  158.         similar systems, such as two memory boards on a 68030 based system
  159.         against each other for relative efficiency.
  160.  
  161.      --    Two new tests have been added to AIBB's lineup.  The first,
  162.         "EllipseTest" is a simple test of one of the Amiga's more complex
  163.         drawing functions, DrawEllipse().  A series of elliptical shapes
  164.         is drawn, with the function timed for speed comparisons.  The
  165.         second test, known as LineTest, tests the Amiga's speed at various
  166.         line drawing jobs.  This test reports its results in terms of
  167.         Lines Drawn per Second.
  168.  
  169.      --    File requester capability has been added to the Load Module
  170.         Preferences requester as per recommendation by various people.
  171.         The gadgets marked "FR" next to each string input gadget will
  172.         bring up a file requester for that particular entry.  This
  173.         alleviates the need to type in path/file names for selecting
  174.         default modules to load up when AIBB is initialized.
  175.  
  176.      --   A bug with AIBB's low memory situation handling has been fixed.
  177.         Previously, it was possible for AIBB to crash in a low memory
  178.         situation when it couldn't open a screen or window.  This has been
  179.         corrected in this version and AIBB should now properly handle these
  180.         events.
  181.  
  182.      --    Changes have been made to AIBB's FPU clock rate evaluation.
  183.         Under previous versions, low results could be reported for the FPU
  184.         clock rate when the host system was running a high-clocked FPU
  185.         (~50 MHz) with a moderate to low-clocked CPU (~16 MHz).  This
  186.         showed u,p on the A1200 operating with external expansion boards
  187.         equippedwith high-speed FPUs.  The changes made here attempt to
  188.         smooth out this difference and give more accurate results for FPU
  189.         clock rate on these systems.
  190.  
  191.     __     AIBB now uses gadgets rather than menu items for CPU cache
  192.         control.  The gadgets are located on AIBB's main screen in the
  193.         cache status indicator area.
  194.  
  195.     --     Moving from AIBB's main screen to its system information
  196.         display is now accomplished by clicking on the appropriate
  197.         gadget near the comparison information area corresponding to the
  198.         machine information is desired on.  Previously, AIBB used a
  199.         menu arrangement under the "Systems" menu to move to this
  200.         display, and this was complained about as being "clumsy" to
  201.         operate.  The new gadgets are located under the "System Comparison
  202.         Information" section of the main screen, and are set up as the
  203.         row headers for that area.
  204.  
  205.     --     AIBB now encorporates gadgets rather than menu items for
  206.         changing code types used in tests and evaluations.  Previously,
  207.         menu items under the menu "Test Options" were used to change the
  208.         test code types for both the host system and comparison machines.
  209.         This turned out to be more work for the user than necessary, and
  210.         hence the gadget approach was adopted.  The gadgets are located
  211.         next to the evaluation results on the main screen, and allow for
  212.         cycling through the various CPU/FPU code types available for a
  213.         given system.
  214.  
  215.     --      A bug with AIBB's MMU table parsing mechanism has been fixed.
  216.         AIBB normally will parse any active MMU tables in order to find the
  217.         physical location of various system objects.  However, a bug was
  218.         discovered in how AIBB parses tables utilizing long (64 bit) table
  219.         descriptors.  This was originally thought to be fixed some time
  220.         ago, but recently it became obvious this was still in error.  This
  221.         is now fixed and should properly find physical memory locations
  222.         under these MMU setups as well as others.
  223.  
  224.     --     AIBB was inadvertantly making a 2.0+ only OS call within its
  225.         procedures to close a log file being written to.  This could lead to
  226.         a failure and crash on systems runing 1.3 or earlier versions of
  227.         AmigaOS.  This has been corrected as of this version.
  228.  
  229.  
  230. Changes to version 5.5
  231.  
  232.     --     The default A3000 internal comparison machine is one using
  233.         AmigaOS 2.x now instead of 3.0 as in the previous 5.0 release
  234.         of AIBB.  This is to reflect the fact that AmigaOS 3.0 is not
  235.         openly available for the A500/A2000/A3000 series machines
  236.         presently.
  237.  
  238.     --     AIBB no longer checks for, nor has problems with Enforcer
  239.         running on the system.   Therefore, the option to avoid testing
  240.         for it has been removed from the CLI/Icon Tooltypes checking.
  241.         Note that although AIBB coexists fine with Enforcer now, such
  242.         should not really be used when testing as the MMU table lookups
  243.         which Enforcer causes can affect peformance to some degree.
  244.  
  245.     --     A bug with AIBB's cache selection menu items has been corrected.
  246.         In version 5.0, AIBB would not disallow selection of the data
  247.         cache enable/disable menu item on a stock 68000 based machine.
  248.         Selection of this could cause a system failure on a 68000 system
  249.         (which has no caches), and has been fixed in this version.
  250.  
  251.     --     Several test result indicators have changed.  The Writepixel
  252.         test no longer gives data in terms of execution time, but rather
  253.         a rating of pixels output per second by the routine.  The MemTest
  254.         routine gives its results in megabytes of data transferred per
  255.         second.  This change was made to make the results more context
  256.         readable.
  257.  
  258.     --     The TGTest test has been updated.  The new version reflects
  259.         effects occuring in a windowed environment for more accurate
  260.         representation of the Amiga under such circumstances.  As such,
  261.         AIBB's load file format has -CHANGED- again.  Unfortunately, test
  262.         updates do require this action, though I am actively seeking
  263.         a remedy for these inconvieniences.
  264.  
  265.     --     A new test called "EmuTest" has been added in the area of
  266.         "special: tests for AIBB.  This test is basically a small
  267.         CPU emulator core running an instruction set simulation
  268.         (basically a small program).  The Amiga seems to have gained
  269.         a bit of a precedence in CPU emulation, and I put together this
  270.         test for the purpose of showing various systems' ability to
  271.         perform such emulation efficiently and speedily.  The simulated
  272.         CPU is a standard 68000, though the results from this can be
  273.         taken as indicative of other CPU emulators as the basic
  274.         principle is the same.  All instructions and internal operations
  275.         are completely software emulated.  The results for this test are
  276.         given in Simulated MegaHertz, basically a rating showing how
  277.         fast the emulation is towards an equivalent hardware-based
  278.         CPU.
  279.  
  280.     --     A change was made in how AIBB stores its test timing data.
  281.         Previously, this data was kept (both internally and in the
  282.         load files) in longword (32 bit) integer format.  However, due
  283.         to some internal changes, this data is now kept in IEEE double
  284.         precision floating-point format (64 bits).  This was done to
  285.         help avoid rounding errors and make internal calculations simpler.
  286.  
  287.     --     By request, standard keyboard shortcuts have been added to
  288.         selected portions of AIBB's menus.
  289.  
  290.     --     Fixed a problem with Parse_MMU_Table().  This function was
  291.         not correctly parsing long-format (double longword) sized
  292.         descriptor tables.  This has been corrected and these tables
  293.         and the addresses AIBB attempts to correlate when looking at
  294.         functioning MMU setups should be checked correctly.  The bug
  295.         did not show up under any currently used MMU setups on the
  296.         Amiga, but could possibly have shown up in the future.  This
  297.         correction assures AIBB will be able to locate physical memory
  298.         addresses from logical ones when reporting the location of
  299.         certain items given in its display.
  300.  
  301.     --     Added some checks in AIBB's System Information Display to
  302.         prevent unnecessary redrawing of parts of the display.  This
  303.         enhancement should speed things up a bit for slower machines.
  304.  
  305.     --     AIBB's 68030/68EC030 detection code has been revised again.
  306.         The new method used should provide a somewhat safer determination
  307.         method than the previous way.
  308.            The old method relied to write protecting a page in a
  309.         translation table setup, then writing to the page and checking for
  310.         a bus error situation.  Unfortunatly, as it turns out some strange
  311.         interactions can occur in the way this was set up if the
  312.         translation table was located in a 16-bit ported RAM resource.
  313.            The method used now is much safer.  Instead of write protecting
  314.         a page, nothing is done whatsoever except for a straight-through
  315.         early-termination one-level setup.  Once the MMU is activated,
  316.         a single read is done from a given page, and then the "U" bit
  317.         in the corresponding page descriptor is examined.  With an active,
  318.         functional MMU, this bit should be set upon the first access to
  319.         a given descriptor, and will be set in the test case above.  On
  320.         68EC030 based machines, which have no functional MMU, this bit will
  321.         be unaffected.
  322.            An added side-effect of these changes is that AIBB no longer
  323.         needs as large of a translation table as it did with the earlier
  324.         method.  A 16 byte table (first level only - upper 2 bits of the
  325.         logical address are used for indexing) is all that is required now,
  326.         as opposed to the 16K byte table used before.  As a result, AIBB
  327.         will almost always be able to allocate memory for a table and will
  328.         not be forced to abort the test due to memory constraints.
  329.  
  330.     --     Fixed a minor memory loss situation.  AIBB was losing about
  331.         40 bytes of memory per incarnation due to a port not being deleted
  332.         upon exit.  This has been corrected as of this revision.
  333.  
  334.     --     A bug with the internal function Scale_Graph() has been
  335.         corrected.  In previous versions, certain odd input circumstances
  336.         could create a worst-case scenario in this function resulting in a
  337.         scaling to infinity.  The result of this was usually a garbled
  338.         screen full of strange display artifacts, and assorted memory
  339.         trashing as AIBB overwrote its RastPort boundaries.  Additional
  340.         checks have been added to avoid this problem.
  341.  
  342.     --     A bug with AIBB's code type selection for comparison systems
  343.         has been fixed.  Earlier, if a module was using 68040 Math code
  344.         and was then replaced by loading a new module incapable of
  345.         using FPU math at all, 68040 Math code would remain selected.
  346.         Normally, AIBB should have stepped the selected type down to
  347.         Standard Math Code.  This bug could have caused problems ranging
  348.         from strange results to system failures under these circumstances.
  349.  
  350.     --     An addition was made to AIBB's System Information Display.
  351.         As well as showing memory nodes and expansion devices, AIBB will
  352.         also show information pertaining to various pertinent system
  353.         libraries (location, version/revision, etc...).  The only libraries
  354.         included in this are those which may have an effect on performance
  355.         issues where AIBB is concerned.  Note that for the memory addresses
  356.         given for each library, the actual node location and memory
  357.         node characteristics can be determined by looking at the various
  358.         system memory nodes and finding the proper one.
  359.  
  360.     --     AIBB now dynamically looks at the system display type in use
  361.         whereas before it only did this on a static at-startup basis.
  362.         This was done to more accurately reflect a systems current true
  363.         state.
  364.  
  365.     --     AIBB's preferences file format has been changed, and thus
  366.         requires the replacement of old preferences files.  This was done
  367.         to add an ID field to the file so that invalid preferences could
  368.         not accidentally be loaded.  This had occured in several incidents,
  369.         so this action was taken as a preventative measure.
  370.  
  371.     --     Some minor cosmetic changes were made to various areas of the
  372.         program, including requesters and general display characteristics.
  373.  
  374. Changes to version 5.0
  375.  
  376.     --     AIBB has been recompiled using SAS/C 6.0, resulting in both
  377.         space savings and a general speed up in code.
  378.  
  379.     --     Note that AIBB's load file format has changed.  Previous load
  380.         files will NOT work with this version.  As of this release, I
  381.         am attempting to freeze the load file format so that further
  382.         inconvieniences do not occur.
  383.  
  384.     --     A bug with AIBB's cache control menu items has been fixed.
  385.         In previous releases, AIBB would request the system CPU type if
  386.         it was not able to determine such by individual means.  This
  387.         occured for checks between the 68EC030 and 68030, and also for
  388.         determining the existance of the 68EC040 or 68LC040, if
  389.         warranted.  However, AIBB would also erroneously disable the
  390.         cache switching menu items if such a request for CPU identification
  391.         was made.  This problem should no longer occur.
  392.  
  393.     --     An expansion board indentification lookup table has been added
  394.         internally to AIBB, allowing various system expansion boards to
  395.         be identified by name.  This table is by no means complete, and
  396.         will be added to in the future (unlisted boards are given a
  397.         "No Information Available" entry when referenced).  This
  398.         information is found under AIBB's System Information Display when
  399.         viewing system expansion devices.
  400.  
  401.     --     A change has been made in the comparison systems AIBB uses.
  402.         The current default systems AIBB contains are now the A4000,
  403.         A3000, A2000 (with FAST RAM), and A500 (stock, no FAST RAM).
  404.         These systems represent a spread of Amiga models currently
  405.         available.
  406.  
  407.     --     Some of AIBB's CLI/Shell arguments have been changed to
  408.         reflect internal changes to the program.  Please note the new
  409.         assignments for CPU/FPU/MMU types (if used) in the main
  410.         documentation file.  This is important - using the incorrect
  411.         assignment if these options are necessary may result in
  412.         unexpected program behavior.
  413.  
  414. Changes to version 4.65
  415.  
  416.     --     AIBB will now request the user to identify whether a 68EC030
  417.         or standard 68030 exists on such systems, or between a 68LC040
  418.         and 68EC040 if conditions warrant.  Previous releases simply
  419.         made a processor assumption if situations did not allow for a
  420.         full internal test for the processor type.  As of this version,
  421.         the user will be prompted for the correct processor type if this
  422.         situation arises.  This was added for accuracy, and some
  423.         safety considerations.
  424.  
  425.     --     The memory port width testing code AIBB uses has been changed.
  426.         The new code used is more accurate, and better able to handle
  427.         a wide variety of memory response configurations.
  428.  
  429.     --     Proper identification of the new custom chips is not done
  430.         within AIBB.  Both the new Alice and Lisa devices will be detected
  431.         and shown on the System Information Display portion of AIBB.
  432.  
  433.     --     Under V39 (3.0) of AmigaOS and above, certain CHIP RAM
  434.         characteristics will be recorded and displayed in the System
  435.         Information Display in the memory node information area.  These
  436.         include CAS characteristics of CHIP memory, and other related
  437.         bandwidth information.
  438.  
  439.     --     Several "safety measure" improvements have been made internally
  440.         to AIBB to close several holes which could cause user problems.
  441.  
  442.     --     AIBB will now copy the paths of load file modules to the
  443.         load file preferences when they are first called up.  This allows
  444.         user selection of available modules from the standard requester
  445.         used when gathering such modules.
  446.  
  447. Changes to versions 4.58 - 4.61
  448.  
  449.     --     Some display bugs were discovered and corrected in these
  450.         interim releases.  Also, some additional work was done on AIBB's
  451.         68030/68EC030 detection.  Version 4.61 corrected a problem with
  452.         4.60's erroneous display of the system's graphics and display
  453.         chips.
  454.  
  455. Changes to version 4.57
  456.  
  457.     --     A rather nasty bug cropped up in version 4.56 pertaining to
  458.         the way AIBB tested for an MMU on the system.  This led to AIBB
  459.         hanging on startup with certain system configurations.  The
  460.         bug is now corrected in this version.
  461.  
  462. Changes to version 4.56
  463.  
  464.     --     Minor changes made to AIBB's 68EC030 testing to improve
  465.         memory usage.  A number of small changes were also made elsewhere
  466.         to this effect as well.
  467.  
  468.     --     Specific time-dependent routines within the interface have been
  469.         downcoded to assembly for speed purposes.
  470.  
  471. Changes to version 4.55
  472.  
  473.     --     AIBB's system information display has been changed.  No longer
  474.         is a simple area used to display memory nodes existing on the
  475.         system.  In its place, a similar area exists, which can be used
  476.         to show either memory nodes, or expansion boards contained
  477.         in the system AutoConfig board lists.  Selection of one of these
  478.         displays is done dynamically by means of gadgets.  Please see
  479.         the main documentation for full information.
  480.  
  481.     --     A new menu item on the main screen, "Show Aggregate Results"
  482.         exists under the "Special" group.  This item will allow the
  483.         viewing of aggregate system results after an initial system load
  484.         module is performed on the host.  The main documentation includes
  485.         full details on this item's use.
  486.  
  487.     --     AIBB now uses the graphics.library DisplayInfo database under
  488.         V36 and above of the OS (2.0 or higher) rather than other means
  489.         to determine the system display characteristics.  This avoids
  490.         unecessary hardware peeking and enhances future compatibility.
  491.  
  492.     --     An annoyance bug with AIBB's startup has been corrected.  In
  493.         certain circumstances (especially on single-floppy systems) when
  494.         AIBB is in its initial startup phases, the program may seem to
  495.         suddenly stop on a blank screen.  This is because the system
  496.         was requesting a different volume (usually the main system disk)
  497.         to be inserted.  However, AIBB's screen was made home to such
  498.         requesters, but too soon - The screen colors were all still black,
  499.         thus rendering the system requester invisible.  Now, AIBB waits
  500.         until it is up and running before transfering the system requester
  501.         location to its own screen so that these requesters will be
  502.         visible should the appear (note that in terms of
  503.         "system requesters", this referrs to requesters related to AIBB's
  504.         process only).
  505.  
  506.     --     A bug with the detection of the 68EC030 CPU has been corrected.
  507.         The method used to detect the EC030 is a fairly straightforward one.
  508.         If the MMU ENABLED bit is set in the translation control register
  509.         ( TC ), AIBB assumes that a working MMU exists, and that the CPU
  510.         is a standard 68030.  If this bit is not set, a more thorough test
  511.         is performed.  This test involves setting up a simple translation
  512.         table, marking a page as 'write protected', and attempting a
  513.         write to that page.  If a bus error occurs, this will have been
  514.         caused by the MMU, and thus it must be functional - implying a
  515.         standard 68030.  If no bus error is forthcoming, the CPU is thus
  516.         marked as a 68EC030.
  517.           The bug was detected only as a fluke, but could show up in other
  518.         systems in an odd circumstance.  Earlier versions of AIBB write
  519.         protected the page in question, turned the MMU on, then installed
  520.         a bus error handler.  This order was incorrect...the circumstance
  521.         in question came up when the system exception vector table was
  522.         moved by use of the Vector Base Register ( VBR ).  If that table
  523.         happened to reside in the page AIBB write protected, the
  524.         installation of the bus error handler pointer in that table would
  525.         cause a bus error itself -- this would hang the system as the
  526.         proper error handler would not be installed (the write to do so
  527.         would be suspended).  This has been corrected.  Thus far, it has
  528.         not shown up on other systems, but this will make it more
  529.         bullet-proof in that respect.
  530.  
  531.     --     A rather obscurely discovered Enforcer hit with AIBB has been
  532.         corrected.  Under strange circumstances, AIBB could cause a READ
  533.         Enforcer hit during its file-requester procedures.  This was
  534.         benign, but nevertheless has been corrected.
  535.  
  536. Changes to version 4.5
  537.  
  538.     --     PLEASE NOTE THAT AIBB'S LOAD FILE FORMAT HAS CHANGED AS OF THIS
  539.        VERSION!  Previous load file formats will no longer be loaded.  I
  540.        have frozen the load file format as of this version, so no future
  541.        changes will cause this incompatibility, or some form of conversion
  542.        ability will be given.
  543.  
  544.     --     New routines have been added for 68040 floating point math
  545.        support.  The 68040 does not have transcendental function support
  546.        within its built-in FPU, and thus must rely on software emulation
  547.        for such routines.  Unfortunately, the method of such emulation
  548.        requires that the FPU jump to a trap routine after encountering such
  549.        a transcendenal function instruction, such as FSIN.<fmt>.  The
  550.        68040 FPU reacts to such instructions by causing an unimplemented
  551.        instruction exception, and fetching the appropriate exception
  552.        routine vector from the system exception vector table.  Once jumping
  553.        to the appropriate routine, it is said routine's responsibility
  554.        to determine the instruction which caused the exception, and
  555.        react accordingly.  In the case of the FPU instructions not
  556.        implemented, the routine must emulate these instructions and set up
  557.        the return result before returning the CPU/FPU to normal processing.
  558.            The unfortunate part to all this is that although the supported
  559.        instructions in the 68040 FPU are highly optmized, and much faster
  560.        than earlier coprocessor equivalents, the overhead involved with
  561.        the trap routine method of emulation is so much so that it negates
  562.        the gain made by the optimizations.  This is where in-line code
  563.        support comes to an advantage with the 68040 FPU, and AIBB attempts
  564.        to do this by making function calls to optimized equivalent math
  565.        routines, rather than allow the trap handling technique to handle
  566.        unimplemented FPU instructions.  Hopefully this will show somewhat
  567.        of a performance improvement on transcendenal-intensive routines
  568.        such as the Savage benchmark.
  569.  
  570.     --     AIBB now accepts certain command-line/icon tooltype options.
  571.        Please refer to the documentation for a description of these
  572.        options.
  573.  
  574.     --     A new comparison is now made upon completion of a load module
  575.        or all-tests run.  AIBB will open a small requester-like window
  576.        after all tests are completed giving a rundown average comparison
  577.        in both integer/graphic and floating-point categories.  The index
  578.        values given represent overall average figures taking into account
  579.        all tests in a given category.
  580.  
  581.     --     The WritePixel test has been updated.  It is now longer and
  582.        performs more graphics operations.
  583.  
  584.     -- A new test has been incorporated - InstTest.  This test is an
  585.        instruction execution timing setup, and will give results in
  586.        Instructions/Second.  It is a special test, and is not affected by
  587.        the individual system code type settings.  Please read the
  588.        appropriate section in the documentation for more information.
  589.  
  590.     --     AIBB's primary screen has been reduced from a 4-bitplane
  591.        ( 16 color ) setup to a 3-bitplane ( 8 color ) one.  This should
  592.        speed up refresh time and responsiveness of the program to some
  593.        extent.
  594.  
  595.     --     A number of internal routine optimizations have been made to
  596.        increase overall program efficiency.
  597.  
  598. Changes to version 4.3
  599.  
  600.      -- AIBB can now be made to incorporate load files upon startup
  601.         as the default comparison systems.  A new entry under the
  602.         General menu, "Load Module Prefs" allows load modules to be
  603.         selected by path/filename for loading into AIBB upon startup.
  604.         This allows alternate comparison systems to be more easily
  605.         used as manual loading of them is no longer necessary if they
  606.         are frequently used instead of the defaults.
  607.  
  608.      -- Corrected a minor problem with AIBB's data display.  Under
  609.         Review Mode, AIBB would not change the system base immediately
  610.         when a new base was selected and there was no test data for
  611.         the host system in reference to any particular test.  This
  612.         has been changed so that AIBB handles this condition correctly.
  613.  
  614.      -- Improvement of AIBB's memory bus port width determining code has
  615.         been added.  Some 68040 boards with 32-bit memory were being
  616.         incorrectly noted as having 16-bit ports.  In addition, a few
  617.         68030 accelerators without memory were having 16-bit resources
  618.         on the system erroneously reported as 32-bit ported devices.
  619.         This has hopefully been corrected in this release.
  620.  
  621. Changes to version 4.2
  622.  
  623.      -- The ability to display data in Review Mode, without having to
  624.         perform a given test on the host system itself has been added.
  625.         This allows the viewing of comparison system data without having
  626.         to perform a given test on the host itself.  The host system
  627.         will display "N/A" in appropriate locations if no data is
  628.         available for a given test.
  629.  
  630.      -- 68040 systems would display Write Allocation and BURST mode
  631.         operations for cache status incorrectly.  Write Allocation is
  632.         not a seperate entity as with the 68030 for the data cache,
  633.         and thus this mode is not displayed for the 68040 now.  BURST
  634.         mode operations for both instruction and data caches are hardware
  635.         controlled on the 68040, and always implied.  The caches do not
  636.         have a software-controllable setting for this mode as with the
  637.         68030, therefore this mode is always indicated as ON with a
  638.         68040 system now.
  639.  
  640.      -- Corrected a bug with AIBB's MMU table parsing code.  AIBB would not
  641.         have correctly handled 8-byte descriptor entries in 68851 or 68030
  642.         MMU tables as it was.  This has been fixed so that AIBB will
  643.         properly parse these entries as well.
  644.  
  645.      -- Bug pertaining to error output strings for the initialization abort
  646.         routine was fixed.  A string was improperly terminated resulting in
  647.         an output error and possible crash for certain startup abort
  648.         conditions.
  649.  
  650.      -- Utility ModInfo was not displaying proper MMU status information for
  651.         68040 system modules.  This has been corrected.  ModInfo now stands
  652.         at version 1.2.
  653.  
  654.      -- Documentation improvements and update information added.
  655.  
  656.      -- General code clean up performed and further optimization of
  657.         various routines.
  658.  
  659. Changes to version 4.1
  660.  
  661.      -- Fixed a bug with certain 68040 system configurations which caused
  662.         AIBB to hang on startup.
  663.  
  664. Changes to version 4.01:
  665.  
  666.      -- Fixed a bug pertaining to early versions of the kd_freq.library.
  667.         Apparently early versions of this library would crash AIBB during
  668.         startup due to a problem with the library itself.  Later library
  669.         versions work fine.  AIBB will therefore not open kd_freq.library
  670.         unless the version number is 3 or greater.
  671.  
  672.      -- A bug with the the included AIBB utility ModInfo was discovered.
  673.         Incorrect information was given pertaining to load modules under
  674.         certain circumstances.  This has been corrected.
  675.  
  676. Primary new features to version 4.0 include:
  677.  
  678.      -- Improved CPU/FPU clock speed evaluation code.  Earlier versions
  679.         had a great many problems in this area, primarily due to a
  680.         misplaced NOP instruction wreaking havoc with the timings.
  681.  
  682.      -- Enhanced/additional tests.  Some tests in earlier versions were
  683.         proven to be non-useful in any real form and were removed.
  684.         The remaining tests were enhanced and refined, and new tests
  685.         were added to further complete the package.
  686.  
  687.      -- Improved system information.  More pertinent information is
  688.         given towards evaluation of AIBB's benchmark performance.
  689.  
  690.      -- Module save/load capability.  AIBB now incorporates the ability
  691.         to create "load modules" consisting of saved test/machine
  692.         evaluations.  These modules may be loaded into AIBB at convienience
  693.         and used within comparisons.  This is an effort to allow
  694.         comparisons across many machine types, rather than restricting
  695.         them to in-built figures.  A set of internal defaults is included.
  696.  
  697.      -- AIBB has been made more "aware" of the system it is operating
  698.         on and will attempt to keep users informed of situations which
  699.         may prove detrimental to performance analysis.
  700.  
  701. Further description of these and other features is found in the main
  702. documentation.
  703.  
  704.